Safety, privacy, backups, and recovery
The app protects its own transactions aggressively. It does not replace a backup, encrypt readable metadata, or make the only copy of your source footage safe.
Where your data lives
The local metadata library is:
~/Library/Application Support/After2AMManager/library.sqlite
It contains channel, strategy, planning, episode, file-location,
media, template, asset, workflow, and internal note data. The
linked Script.md remains the portable canonical episode
script. Episode media lives in the storage folders you choose and
is not embedded in SQLite.
macOS account permissions protect the database from other normal users, but its contents are not encrypted. Enable FileVault and use encrypted backup destinations when titles, notes, schedules, or file locations are sensitive.
Protections that are always on
Protect editing-project links
When the app starts or reloads its library, it cleans the
filenames of catalogued managed media when necessary. This
includes recordings discovered directly inside an episode’s
Footage tree. Punctuation other than hyphens and
underscores becomes spacing, apostrophes are removed, and a
collision receives a numeric suffix. The file is physically
renamed and the After2AM catalogue is updated.
An editing project created before that cleanup can retain the
old path and show the clip as offline. Use portable names at
capture time, or restart After2AM Studio after discovery and
verify the final filenames in Finder before importing clips
into DaVinci Resolve or another editor. This cleanup never
renames an external source selected for a normal copy import;
it applies to the managed copy. For direct recordings, the
file in Footage is itself that managed copy.
Build a backup plan around the app
- Keep original camera media untouched. Do not erase cards or source disks merely because import reports success.
-
Back up the complete local library folder.
Include the complete
After2AMManagerApplication Support folder in a regular independent backup. Do not copy only a livelibrary.sqlitewhile its WAL is active. - Back up Primary storage. The catalogue knows where a file should be; it cannot recreate lost media.
- Back up Archive storage. An archive moves the working folder; it does not create redundancy by itself.
- Test restore. Periodically recover both metadata and representative media to a safe location.
Catalogue recovery
At the beginning of a writable session, the app uses SQLite's
backup mechanism to retain a coherent, verified snapshot under
library-backups. If the main database is unreadable,
the app first makes collision-safe, byte-verified
library.corrupt-* rescue copies of the database and
any existing WAL/SHM sidecars.
If the required session snapshot cannot be created, the verified live database stays in place and remains visible, but library writes are blocked until backup access is restored and the library is reloaded or the app is reopened. A backup-path failure is not treated as database corruption.
If that rescue copy cannot be created, the original remains untouched and metadata writes fail closed. The app will not silently replace irreplaceable unreadable bytes with sample data. A database created by a newer app version is also left untouched.
Treat “Changes may not be saved” as blocking
This global banner means the in-memory view and the durable library may differ. Stop making production assumptions based on recent edits.
- Choose Retry save. Resolve a temporary disk, permission, or capacity problem first when known.
- Choose Reveal library. Preserve the complete containing folder, including any SQLite sidecars and recovery material.
- Preserve newly written media. A verified copy can exist even when its catalogue entry could not be saved.
- Do not quit until the situation is understood. Never assume the latest visible change is durable while the warning remains.
Save and recovery are different
Long-form editors keep changes as an in-memory draft until you choose Save or press Command-S. Discard returns to the last committed version. Leaving a document does not silently turn its draft into committed library data.
For crash protection, Studio takes the first changed recovery snapshot after about five seconds, then at most once a minute when the draft changed, and once more when leaving the editor or app. On relaunch you can resume or discard it. If the committed note or external script changed too, Studio reports a conflict rather than choosing one version behind your back.
Interrupted operation recovery
Hidden import, thumbnail, episode, and transfer staging items left by an old interrupted process are not silently deleted. After a 24-hour grace period, they move beneath the affected root to:
After2AM Recovery/Interrupted Operations/
Review recovered items before disposal. Script drafts use their own Recovery Drafts folder and are presented through the script editor’s conflict-aware recovery flow.